一文带你看通透，MySQL事务ACID四大特性实现原理

hello，大家好，我是张张，「架构精进之路」公号作者。

说起MySQL事务处理的四大特性，相信大家都可以张口就来：ACID！

那 MySQL是如何实现ACID的？每种特性的原理又是如何实现的？

今天，本文笔者主要探讨MYSQL InnoDB引擎下的ACID实现原理，对事务、锁以及隔离级别等内容统一进行回顾一下。

1、ACID特性

• 原子性（Atomicity）

单个事务，为一个不可分割的最小工作单元，整个事务中的所有操作要么全部commit成功，要么全部失败rollback，对于一个事务来说，不可能只执行其中的一部分SQL操作，这就是事务的原子性。

• 一致性(Consistency)

数据库总是从一个一致性的状态转换到另外一个一致性的状态。在前面的例子中， 一致性确保了，即使在执行第三、四条语句之间时系统崩溃，信用卡账户也不会损 失100块，因为事务最终没有提交，所以事务中所做的修改也不会保存到数据库中，保证数据一致性。

• 隔离性(Isolation)

通常来说，一个事务所做的修改在最终提交以前，对其他事务是不可见（隔离）的。避免多个事务并发执行的时候不会互相干扰。

• 持久性（Durability）

一旦事务提交，则其所做的修改就会永久保存到数据库中，之后的其他操作或故障都不会对事务的结果产生影响。

2、ACID 具体实现

• 原子性：通过undolog来实现。
• 持久性：通过binlog、redolog来实现。
• 隔离性：通过（读写锁+MVCC）来实现。
• 一致性：MySQL通过原子性、持久性、隔离性最终实现数据一致性。

对MySQL来说，逻辑备份日志（binlog）、重做日志（redolog）、回滚日志（undolog）、锁技术 + MVCC就是MySQL实现事务的基础。

2.1  原子性原理

事务通常是以BEGIN TRANSACTION 开始，以 COMMIT 或 ROLLBACK 结束。

• COMMIT 表示提交，即提交事务的所有操作并持久化到数据库中。
• ROLLBACK表示回滚，即在事务中运行的过程中发生了某种故障，事务不能继续执行，系统将事务中对数据库所有已完成的操作全部撤销，回滚到事务开始时的状态，这里的操作指对数据库的更新操作（查询操作忽略）。这时候需要用到 undolog 来进行回滚。

undolog：

每条数据变更（INSERT/UPDATE/DELETE/REPLACE）等操作都会生成一条undolog记录，在SQL执行前先于数据持久化到磁盘。

• insert语句，回滚时会执行 delete；
• delete语句，回滚时会执行insert；
• update语句，回滚时便执行相反的update，把数据改回来。

当事务需要回滚时，MySQL会根据回滚日志对事务中已执行的SQL做逆向操作，比如 DELETE 一行数据的逆向操作就是再把这行数据 INSERT回去，其他操作同理。

undolog记录事务开始前老版本数据，用于实现回滚，保证原子性，实现MVCC，会将数据修改前的旧版本保存在undolog，然后行记录有个隐藏字段回滚指针指向老版本。

2.2 持久性原理

我们知道，MySQL表数据是持久化到磁盘中的，但如果所有操作都去操作磁盘，等并发上来了，那处理效率无法保证，因此引入了缓冲池(Buffer Pool)的概念，Buffer Pool 中包含了磁盘中部分数据页的映射，可以当做缓存来用；这样当修改表数据时，我们把操作记录先写到Buffer Pool中，并标记事务已完成，等MySQL空闲时，再把更新操作持久化到磁盘里，从而大大缓解了MySQL并发压力。

MYSQL的持久性便是由redo log来保证。

redo log

是一种物理日志，作用：会记录事务开启后对数据做的修改，crash-safe。

它类似于一个卸货的小推车，我们若是每卸一件物品就拿着去入库，那岂不是特浪费时间，若有一个小推车，我们将货物首先存放在小推车，当推车满了再往库里存，可以大大提升效率。

其实就是MySQL里经常说到的WAL技术，WAL的全称是Write-Ahead Logging，它的关键点就是先写日志，再写磁盘，也就是先装小推车，等不忙的时候再装库。

特性：空间一定，写完后会循环写，有两个指针write pos指向当前记录位置，checkpoint指向将擦除的位置，redolog相当于是个取货小车，货物太多时来不及一件一件入库太慢了这样，就先将货物放入小车，等到货物不多或则小车满了或则店里空闲时再将小车货物送到库房。用于crash-safe，数据库异常断电等情况可用redo log恢复。

以下只作了解：

写入流程：先写redo log buffer，然后wite到文件系统的page cache，此时并没有持久化，然后fsync持久化到磁盘

写入策略：根据innodb_flush_log_at_trx_commit参数控制（innodb以事务的什么提交方式刷新日志）

0——>事务提交时只把redo log留在redo log buffer

1——>将redo log直接持久化到磁盘（所以有个双“1”配置，后面会讲）

2——>只是把redo log写到page cache

2.3 隔离性原理

MYSQL有四种隔离级别，用来解决存在的并发问题：脏读、幻读、不可重复读。

那么不同隔离级别，隔离性是怎样实现的呢？

一句话：锁+MVCC。

锁

• 表锁：读锁（不会阻塞其他线程的读操作，阻塞写操作）；写锁（读写操作都阻塞）

• 行锁：需要的时候加上，并不是马上释放，等事务提交才释放，两阶段锁协议

• 锁的类型

• 间隙锁-gap lock：锁定区间范围，防止幻读，左开右开，只在可重复读隔离级别下生效—|—为了阻止多个事务将记录插入到同一范围内，而这会导致幻读问题的产生

• 记录锁-record Lock：锁定行记录，索的索引，索引失效，为表锁

• 临键锁-next-key Lock：record lock+gap lock 左开右闭（解决幻读）

• 锁的模式

• select .... for update （持有写锁，别的不可加读锁，也不可加写锁）

• select .... lock in share mode（持有读锁，别的可以再加读锁，不可加写锁）

• 共享锁-读锁-S锁

• 排他锁-写锁-X锁

• 意向锁：读意向锁+写意向锁

• 自增锁

• 全局锁：全库逻辑备份

• 死锁：两个或多个事务在同一资源上相互占用，并请求加锁时，造成相互等待，无限阻塞

MVCC：实现多版本并发控制，实现原理：使用版本链+Read View

读已提交和可重复读实现原理就是MVCC Read View不同的生成时机。可重复读只在事务开始时生成一个Read View，之后都用的这个；读已提交每次执行前都会生成Read View。

2.4 一致性原理

一致性是事务追求的最终目标，前文所述的原子性、持久性和隔离性，其实都是为了保证数据库状态的一致性，数据库中的增删改操作，使数据库不断从一个一致性的状态转移到另一个一致性的状态。

总结

事务该回滚的回滚，该提交的提交，提交后该持久化磁盘的持久化磁盘，该写缓冲池的写缓冲池+写日志。

对于数据可见性，通过四种隔离级别进行控制，使得库表中的有效数据范围可控，保证业务数据的正确性的前提下，进而提高并发程度，支撑服务高QPS的稳定运行，保证数据的一致性，这就是咱们说个不停的MySQL数据库事务ACID四大特性。

---

往期热文推荐：

关注公众号，免费领学习资料

如果您觉得还不错，欢迎关注和转发~